<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic
  PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<topic id="topic1"><title id="es20941">VALUES</title><body><p id="sql_command_desc">Computes a set of rows.</p><section id="section2"><title>Synopsis</title><codeblock id="sql_command_synopsis">VALUES ( <varname>expression</varname> [, ...] ) [, ...]
   [ORDER BY <varname>sort_expression</varname> [ ASC | DESC | USING <varname>operator</varname> ] [, ...] ]
   [LIMIT { <varname>count</varname> | ALL } ] 
   [OFFSET <varname>start</varname> [ ROW | ROWS ] ]
   [FETCH { FIRST | NEXT } [<varname>count</varname> ] { ROW | ROWS } ONLY ]</codeblock></section><section id="section3"><title>Description</title><p><codeph>VALUES</codeph> computes a row value or set of row values specified by value expressions.
                It is most commonly used to generate a "constant table" within a larger command, but
                it can be used on its own.</p><p>When more than one row is specified, all the rows must have the same
number of elements. The data types of the resulting table's columns
are determined by combining the explicit or inferred types of the expressions
appearing in that column, using the same rules as for <codeph>UNION</codeph>.
</p><p>Within larger commands, <codeph>VALUES</codeph> is syntactically allowed
                anywhere that <codeph>SELECT</codeph> is. Because it is treated
                like a <codeph>SELECT</codeph> by the grammar, it is possible to
                use the <codeph>ORDER BY</codeph>, <codeph>LIMIT</codeph> (or
                equivalent <codeph>FETCH FIRST</codeph>), and
                    <codeph>OFFSET</codeph> clauses with a
                    <codeph>VALUES</codeph> command.</p></section><section id="section4"><title>Parameters</title><parml><plentry><pt><varname>expression</varname></pt><pd>A constant or expression to compute and insert at the indicated place
in the resulting table (set of rows). In a <codeph>VALUES</codeph> list
appearing at the top level of an <codeph>INSERT</codeph>, an expression
can be replaced by <codeph>DEFAULT</codeph> to indicate that the destination
column's default value should be inserted. <codeph>DEFAULT</codeph>
cannot be used when <codeph>VALUES</codeph> appears in other contexts.</pd></plentry><plentry><pt><varname>sort_expression</varname></pt><pd>An expression or integer constant indicating how to sort the result rows. This expression may
                        refer to the columns of the <codeph>VALUES</codeph> result as
                            <codeph>column1</codeph>, <codeph>column2</codeph>, etc. For more
                        details, see "The ORDER BY Clause" in the parameters for <codeph><xref
                                href="SELECT.xml#topic1"/></codeph>.</pd></plentry><plentry><pt><varname>operator</varname></pt><pd>A sorting operator. For more details, see "The ORDER BY Clause" in the parameters for
                                <codeph><xref href="SELECT.xml#topic1"/></codeph>. </pd></plentry><plentry><pt>LIMIT count</pt><pt>OFFSET start</pt><pd>The maximum number of rows to return. For more details, see "The LIMIT Clause" in the parameters
                        for <codeph><xref href="SELECT.xml#topic1"/></codeph>.</pd></plentry></parml></section><section id="section5"><title>Notes</title><p><codeph>VALUES</codeph> lists with very large numbers of rows should
be avoided, as you may encounter out-of-memory failures or poor performance.
<codeph>VALUES</codeph> appearing within <codeph>INSERT</codeph> is a
special case (because the desired column types are known from the <codeph>INSERT</codeph>'s
target table, and need not be inferred by scanning the <codeph>VALUES</codeph>
list), so it can handle larger lists than are practical in other contexts.</p></section><section id="section6"><title>Examples</title><p>A bare <codeph>VALUES</codeph> command: </p><codeblock>VALUES (1, 'one'), (2, 'two'), (3, 'three');</codeblock><p>This will return a table of two columns and three rows. It is effectively
equivalent to:</p><codeblock>SELECT 1 AS column1, 'one' AS column2
UNION ALL
SELECT 2, 'two'
UNION ALL
SELECT 3, 'three';</codeblock><p>More usually, <codeph>VALUES</codeph> is used within a larger SQL command.
The most common use is in <codeph>INSERT</codeph>:</p><codeblock>INSERT INTO films (code, title, did, date_prod, kind)
    VALUES ('T_601', 'Yojimbo', 106, '1961-06-16', 'Drama');</codeblock><p>In the context of <codeph>INSERT</codeph>, entries of a <codeph>VALUES</codeph>
list can be <codeph>DEFAULT</codeph> to indicate that the column default
should be used here instead of specifying a value: </p><codeblock>INSERT INTO films VALUES
    ('UA502', 'Bananas', 105, DEFAULT, 'Comedy', '82 
minutes'),
    ('T_601', 'Yojimbo', 106, DEFAULT, 'Drama', DEFAULT);</codeblock><p><codeph>VALUES</codeph> can also be used where a sub-<codeph>SELECT</codeph>
might be written, for example in a <codeph>FROM</codeph> clause:</p><codeblock>SELECT f.* FROM films f, (VALUES('MGM', 'Horror'), ('UA', 
'Sci-Fi')) AS t (studio, kind) WHERE f.studio = t.studio AND 
f.kind = t.kind;
UPDATE employees SET salary = salary * v.increase FROM 
(VALUES(1, 200000, 1.2), (2, 400000, 1.4)) AS v (depno, 
target, increase) WHERE employees.depno = v.depno AND 
employees.sales &gt;= v.target;</codeblock><p>Note that an <codeph>AS</codeph> clause is required when <codeph>VALUES</codeph>
is used in a <codeph>FROM</codeph> clause, just as is true for <codeph>SELECT</codeph>.
It is not required that the <codeph>AS</codeph> clause specify names
for all the columns, but it is good practice to do so. The default column
names for <codeph>VALUES</codeph> are <codeph>column1</codeph>, <codeph>column2</codeph>,
etc. in Greenplum Database, but these names might be different in other
database systems.</p><p>When <codeph>VALUES</codeph> is used in <codeph>INSERT</codeph>, the
values are all automatically coerced to the data type of the corresponding
destination column. When it is used in other contexts, it may be necessary
to specify the correct data type. If the entries are all quoted literal
constants, coercing the first is sufficient to determine the assumed
type for all: </p><codeblock>SELECT * FROM machines WHERE ip_address IN 
(VALUES('192.168.0.1'::inet), ('192.168.0.10'), 
('192.0.2.43'));</codeblock><note type="note">For simple <codeph>IN</codeph> tests, it is better to rely on the list-of-scalars
                form of <codeph>IN</codeph> than to write a <codeph>VALUES</codeph> query as shown
                above. The list of scalars method requires less writing and is often more
                efficient.</note></section><section id="section7"><title>Compatibility</title><p><codeph>VALUES</codeph> conforms to the SQL standard. <codeph>LIMIT</codeph>
                and <codeph>OFFSET</codeph> are Greenplum Database extensions;
                see also under <xref href="SELECT.xml#topic1" type="topic"
                    format="dita"/>.</p></section><section id="section8"><title>See Also</title><p><codeph><xref href="INSERT.xml#topic1" type="topic" format="dita"/></codeph>, <codeph><xref
                        href="SELECT.xml#topic1" type="topic" format="dita"/></codeph></p></section></body></topic>
